About SSL certificates

As of 2023.4 the N-able N-central server requires a valid certificate set up on the server. This includes any certificate where the whole chain is validated to a root certificate authority (CA) within the system trust store. You must apply either a globally signed and recognized certificate or a certificate from your own private certificate authority. For any private certificate authority generated certificate, you must update the N-central Trusted Root Certification Authorities Certificate Store. In addition, you must also update the Trusted Root Certification Authorities Certificate Store for any endpoint so that the endpoint is able to connect to the N-central server.

N-able N-central uses an SSL connection to communicate between the N-able N-central server and all monitored devices. By default, the URL of a secure central server begins with HTTPS.

SSL Certificates are only available at the System Level for the System or Product Administrator level accounts. Service Organization and Customer or Site level accounts will not be able to access this feature.

Before you can access N-able N-central over a secure connection, you need to generate a server key and SSL certificate. A generated SSL Certificate is a self-signed certificate. If you would like the certificate signed by a CA, you can download the certificate and send it to the authority. After your receive the signed certificate, you can upload it to N-able N-central.

SSL certificates are used by HTTPS to validate the identity of servers. To make a secure connection, a client needs a mechanism to ensure that the server is valid, SSL certificates serve that purpose.

SSL chain of trust

An individual certificate must be signed by a recognized and trusted CA, for example, Verisign and Go-Daddy. The principle is similar to what you might do when you are told something new. If a random person passes on some information, ordinarily you would not trust it unless the person can tell you the source of their information. You would then consider how trustworthy that source is and evaluate the validity of the information based on that trustworthiness. This is often referred to as a "SSL chain of trust" and comprises:

  • a root certificate
  • one or more Intermediate certificates
  • the server SSL certificate

Root certificate

The base of the certificate chain. Certificates issued by the root CA carry the same level of trust as the root CA certificate. The root CA typically signs the certificate for the intermediate CA

Intermediate certificate

The role of the intermediate CA is to sign end-entity certificates for the root CA. The goal in having the intermediate CA perform this task is to limit exposure to the root CA.

Intermediate certificates exist for several reasons. The validity and authoritativeness of a root certificate would be diluted if it were to sign all certificates itself and so intermediate certificates are delegated to be the CA. In some cases, the CAs will also generate intermediate certificates based on the purpose of the certificates they are signing. For example, temporary certificates are signed using one intermediate certificate while long term certificates are signed using another.

Server SSL certificate

The server certificate contains information such as the website's domain name, the public key of the server, and is digitally signed by the CA or one of its intermediates. The SSL certificate is installed on an SSL enabled server (end-entity) and is presented to the browser when it initiates an SSL connection with the server. The browser will attempt to confirm the authenticity of the end-entity certificate by checking the CA of the certificate.

For a web client to validate certificates, it must include a list of all certificates used to sign the certification offered by a website. As there can be a very large number of intermediate certificates involved, most web servers do not offer only their own certificate. Instead, they present all or most of the certificates obtained between themselves and the root certificate. This bundle of certificates is referred to as a certificate chain. Web browsers have their own certificate stores which contain most, if not all, of the root certificates as well as a number of intermediate certificates which are trusted by default. When a client connects using HTTPS, the client receives the certificate chain from the server and follows it back to a trusted certificate in order to determine the validity of the received certificate.

As with any technology, changes have been made to the certificate system. Some issued certificates are condensed certificates that include all levels as one individual certificate rather than as a chain of certificates. While this is growing in popularity, N-able N-central does not support condensed certificates at this time but relies on a chain of individual certificates.

SSL handshake process (client verifies chain of trust)

During the SSL/TLS handshake process, the client (web browser) verifies the chain of trust as follows:

  • The client receives the server certificate from the server during the handshake.

  • The client checks the validity of the server certificate by verifying its digital signature using the public key of the issuing CA or an intermediate CA.

  • If the certificate is signed by an intermediate CA, the client checks if it trusts the intermediate CA by validating its certificate against the root CA public key. This process continues until a trusted root CA is reached.

  • If the entire chain of trust is valid and trusted, the client considers the server certificate valid and proceeds with the secure connection. Otherwise, it presents a warning or error message to the user.

The SSL chain of trust ensures that the server certificate presented by a website is issued by a trusted CA, which enhances the security and integrity of the SSL/TLS connection. It helps prevent man-in-the-middle attacks and assures users that they are communicating securely with the intended website.

Wildcard SSL Certificates

Wildcard SSL Certificates are certificates assigned to a domain, such as .example.com, and can be applied on any third-level address (mail.example.com, home.example.com) using the same certificate.

You cannot generate or export a wildcard certificate using your N-able N-central server.

The N-able N-central server is able to upload a certificate, but the certificate must already be in a PKCS12 format (.p12 or .pfx), which is password protected and contains the bundle and private key of that server. It will not accept any other format. See Upload a certificate.

PKCS12 Certificates (file format)

A PKCS12 certificate, also known as a PFX (Personal Information Exchange) certificate, is a file format that stores a private key, public key, and digital certificates in a single encrypted file. It is primarily used for secure storage and transport of certificates and private keys in various cryptographic systems.

Handle PKCS12 certificates with care to ensure that the password used to protect the private key is kept secure and confidential.

Here are some key points about PKCS12 certificates:

  • File Format: PKCS12 is a standard file format specified in the Public-Key Cryptography Standards (PKCS) #12 document. It uses a binary format and typically has the file extension ".p12" or ".pfx".

  • Content: A PKCS12 certificate can contain multiple components, including:

    • Private Key: The private key is securely stored within the PKCS12 file. It is encrypted and protected with a password. The private key is used for cryptographic operations such as decrypting data or generating digital signatures.

    • Public Key Certificate: The PKCS12 file can include one or more digital certificates. These certificates are used to establish the identity of the certificate holder and contain the public key corresponding to the private key.

    • Certificate Chain: If the certificate relies on intermediate or root Certificate Authorities (CAs) for verification, the PKCS12 file may also include the necessary intermediate certificates or root certificates that form the certificate chain.

  • Usage and Import/Export: PKCS12 certificates are commonly used for various purposes, including secure storage of certificates and private keys, certificate backup and transfer, and facilitating certificate deployment on different systems. They are compatible with several cryptographic systems, such as SSL/TLS implementations, email encryption, and code signing.

  • PKCS12 certificates can be imported and exported using various software and tools, such as certificate management applications, web browsers, or command-line utilities provided by cryptographic libraries.

  • Password Protection: Since the private key stored in a PKCS12 file is encrypted, access to the file requires a password. It is important to choose a strong and secure password to protect the private key and the certificates stored within the PKCS12 file.

  • Conversion and Interoperability: PKCS12 certificates can be converted to other certificate formats, such as PEM (Privacy-Enhanced Mail) or JKS (Java KeyStore), depending on the requirements of the target system or application. This allows for interoperability between different cryptographic systems.

SSL CAs

Certificate bundles can be obtained from any of the following SSL Certificate providers: